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ABSTRACT 



This thesis develops an architecture for dynamic distributed military operations 
research. This architecture assumes that a network of heterogeneous computing devices 
connects forces throughout the battlespace. Both the raw data about the battlespace and 
the operations research models used to analyze this data are accessible to devices on this 
network. The thesis designs a system using this architecture that invokes operations 
research network optimization algorithms to solve problems involving movement of 
people and equipment over dynamic road networks. A specific application is 
implemented to help a medic find the nearest aid station using a shortest path algorithm. 
This application marshals the most current data on unit locations and road conditions 
(distributed across the computing network) and locates on the network an appropriate 
algorithm that is then used to construct a solution. The answer is returned to the user as a 
web page in a form appropriate for his computing device. The application is 
implemented with existing technologies including the Java computer language, Konig, a 
Java-based tool for representing networks and graphs, and Hypertext Markup Language, 
a format for shared information on the Internet. This system uses operations research 
tools to transform data into decisions in real-time or near real-time. 
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DISCLAIMER 



The reader is cautioned that computer programs developed in this research may 
not have been exercised for all cases of interest. While every effort has been made, 
within the time available, to ensure that the programs are free of computational and logic 
errors, they cannot be considered validated. Any application of these programs without 
additional verification is at the risk of the user. 
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EXECUTIVE SUMMARY 



Military leaders have predicted a future battlefield that is much different than that 
of today. Joint Vision 2010 and the Army Vision 2010 create a framework for planning a 
future force to succeed on that battlefield. Information superiority is the most important 
tenet of Joint Vision 2010 and it can lead to dominant battlespace awareness, providing 
leaders a much more accurate assessment of friendly and enemy operations. Enabling 
technologies, including tactical computers, communications networks, and analytical 
tools that synthesize data from many sources on the battlefield, are key to taking 
advantage of information superiority. 

According to Joint Vision 2010, soldiers on the battlefield will be connected on a 
network of digital computing devices capable of communicating with one another. With 
the explosion of sensors and digital devices on the battlefield, huge amounts of data will 
be collected and will be available to soldiers and decision makers in the battlespace. 
However, access to these data is not sufficient by itself to help these soldiers reach 
decisions. Raw data without any analysis might even hinder decisions, causing the 
decision maker to get lost in minutia and slowing reaction time. Raw data can even 
confuse and overwhelm, leading to incorrect conclusions. Trends and insights in the data 
are often not obvious and require sophisticated tools to uncover. 

Operations research tools can help in this data-rich environment by supporting 
better, faster decisions in real-time and near real-time. The field of operations research 
specializes in using models of the real world to solve problems that provide information 
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and insight to help the decision maker. It has many tools to help decision makers refine 
raw data into decisions. 

To be useful in real-time or near real-time, an operations research model or 
algorithm must execute on existing and future computing devices available in the 
battlespace, and the results of these models must be effectively presented to the decision 
maker to help him make decisions. Currently, most operations research models are not 
designed to operate in this digitally connected environment. Most are designed as stand- 
alone models that operate in specific locations coincident with the data. These operations 
research software tools, models, and algorithms must be redesigned to operate in a future 
environment that consists of dynamic, distributed computing devices, large numbers of 
sensors, huge collections of raw data, and many decision makers working at all levels of 
the battlespace. If the models do all of these things they will have a significant value on 
the battlefield of the future. 

A specific set of problems that current operations research tools can help solve 
involves efficiently moving men and equipment around a road network. The dynamic 
nature of the road network presents a unique problem. Road trafficability can change 
with the weather and with changes in the tactical situation. Roads can be controlled by 
the enemy at one time and then controlled by friendly forces at another. In addition unit 
locations are very dynamic since units move frequently. In general unit locations change 
more fi'equently than the status of the road network. Another complicating factor is the 
dynamic nature of the underlying communications grid on which data flows between 
units. This communications grid is made up of the digital computing devices and the 
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wires and/or radios that connect them. Units enter and leave the communications grid 
with regularity. In fact, the communications grid may not even remain connected. An 
additional challenge is the distributed nature of the data needed to support the models and 
algorithms. Different computers in distinct locations can possess data about the road 
network; collecting and synthesizing this data into a single picture of the battlespace 
presents a formidable task. 

This thesis develops an architecture for dynamic distributed military operations 
research systems that can operate on the future battlefield. Existing network and software 
technologies are used to construct a specific system based on this architecture to optimize 
the movement of people and equipment over a battlespace road network. This system is 
demonstrated by constructing an application that answers the battlefield question, “Where 
is the nearest aid station?” The dynamic nature of the road network, unit locations, and 
the communications network makes this question more difficult than it first appears. 

The road movement system demonstrates the power of the architecture. It takes a 
dynamic road network and a dynamic communications network with distributed data and 
distributed computing power and combines them with an operations research model to 
solve movement problems; it processes data and extracts the information of value to 
decision makers in real-time and near real-time. Data is converted into better, faster 
decisions. This system demonstrates that existing widely used network and software 
technology can be used to construct battlespace decision support systems of the type 
envisioned in Joint Vision 2010 and Army Vision 2010. 
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I. BACKGROUND 



A. JOINT VISION 2010 

Current military leaders are predicting a future battlefield that is much different 
than that of today. [1,2,3] Joint Vision 2010 and the Army Vision 2010 create a 
framework for planning a future force to succeed on that battlefield. The five tenets of 
Joint Vision 2010 are: Information Superiority, Dominant Maneuver, Precision 
Engagement, Full Dimensional Protection, and Focused Logistics. Of these. Information 
Superiority is the enabling technology for the other four tenets. Information Superiority 
will be gained through developing enabling technologies including tactical computers, 
communications networks, and analytical tools to synthesize information from many 
sources on the battlefield. 

Joint Vision 2010 states “Advances in computer processing, precise global 
positioning, and telecommunications will provide the capability to determine accurate 
locations of friendly and enemy forces, as well as to collect, process, and distribute 
relevant data to thousands of locations. Forces harnessing the capabilities potentially 
available from this system of systems will gain dominant battlespace awareness, an 
interactive ‘picture’ which will yield much more accurate assessments of friendly and 
enemy operations.” [1, p.l3] The Army must harness the potential capabilities of these 
systems if it is to achieve these goals. 

As the Army pursues its part of this vision, it is concentrating on developing the 
necessary enabling technologies in order to make the future battlefield different than that 
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of today. With the improvements in digital technology, computers will be much more 
numerous, more powerful, and much smaller than today. Current Army experiments 
include putting a computer on every vehicle and even on every individual soldier. These 
computing devices will be cormected on a digital communications network that will allow 
information to move quickly around the battlespace. [4] Future technologies will solve 
the current limitations on bandwidth. The complex network of digital devices will create 
a huge amount of data. The difficult goal of achieving information superiority will not 
be met by just collecting these data. It will be achieved by taking this glut of data, more 
than can be processed and understood by humans in finite amounts of time, and 
processing it into information that can aid the decision makers. 

B. EMPOWERING DECISION MAKERS 

Decision makers have traditionally been thought of as people high in the 
organizational hierarchy whose decisions have great influence on the battlespace. In the 
future vision of the battlespace, this view of decision makers must be expanded to include 
all people who make decisions down to the lowest levels. Access to the great amounts of 
data should benefit not just the high ranking decision makers at the top of a hierarchical 
structure whose decisions have obvious far reaching effect, but also the soldiers working 
at the lowest level, whose decisions must be made quickly and in accordance with the 
overall intent of the commander. The idea of a self-synchronizing system requires that 
people at the lower levels have much autonomy during the execution phase of an 
operation, and although their decisions may not have as great or immediate an impact as 
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decisions made by higher ranking officers, they are based on the same data sources as the 
decisions made at the highest level. 

A means of collecting and transmitting raw data is required in order to secure this 
vision and truly help decision makers. With the explosion of sensors and digital devices 
on the battlefield, huge amounts of data will be collected, and will be available to 
decision makers in the battlespace. However, access to these data is not sufficient by 
itself to help people reach decisions. Raw data without any analysis might even hinder 
decisions, causing the decision maker to get lost in minutia and slowing reaction time. 
Raw data can even confuse and overwhelm, leading to incorrect conclusions. Trends and 
insights in the data are often not obvious and require sophisticated tools to uncover. 
Operations research models and algorithms can help get important information out of the 
data. Often optimal decisions are not obvious by simply inspecting the data. Operations 
research models and algorithms executing on modem computers can assist in solving 
these difficult problems. They can provide significant value to decision makers who are 
pressed for time and operating in high stress environments. 

C. PUTTING OPERATIONS RESEARCH INTO THIS ENVIRONMENT 

Operations research tools can help in this data-rich environment by supporting 
better, faster decisions in real-time and near real-time. The field of operations research 
specializes in using models of the real world to solve problems that provide information 
and insight to help the decision maker. It has many tools to help decision makers refine 
raw data into decisions. Some examples of operations research tools include 
optimization models, simulation models, and network algorithms. 
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To be useful in real-time or near real-time, an operations research model or 
algorithm must execute on existing and future computing devices available in the 
battlespace, and the results of these models must be effectively presented to the decision 
maker to help him make decisions. Currently, operations research tools exist that help 
decision makers reach good informed decisions. However, most of these tools have been 
designed to run on a single computer that contains all the necessary data and algorithms 
to process the data. The software is often limited to a specific computer system that has a 
specific hardware and software configuration. Many models also output solutions in 
formats that are very technical, making it difficult to show decision makers model output 
without first processing it into an understandable format. These operations research 
software tools, models, and algorithms must be redesigned to operate in a future 
environment that consists of dynamic, distributed computing devices, large numbers of 
sensors, huge collections of raw data, and many decision makers working at all levels of 
the battlespace. If the models can do all of these things they will have a significant value 
on the battlefield of the future. 

D. ROAD MOVEMENT PROBLEMS 

A specific set of problems that current operations research tools can help solve 
involves efficiently moving men and equipment around a road network. Many models 
currently exist to help solve these problems in a static environment, but most of these 
models are not designed to operate in a dynamic environment. The dynamic nature of the 
road network presents a unique problem. Road trafficability can change with the weather 
and with changes in the tactical situation. Roads can be controlled by the enemy at one 
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time and then controlled by friendly forces at another. In addition unit locations are very 
dynamic since units move frequently. Unit locations in general change more frequently 
than the status of the road network. Another complicating factor is the dynamic nature of 
the underlying communications grid on which data flows between units. This 
communications grid is made up of the digital computing devices and the wires and/or 
radios that connect them. Units enter and leave the communications grid with regularity. 
In fact, the communications grid may not even remain connected. An additional 
challenge is the distributed nature of the data needed to support the models and 
algorithms. Different computers in distinct locations can possess data about the road 
network; collecting and synthesizing this data into a single picture of the battlespace 
presents a formidable task. 

A difficult question to answer on the current battlefield is “Where is the nearest 
medical aid station?” This question can mean the difference between life and death when 
evacuating a casualty. With units moving and the status of the road network changing 
this problem is actually much more difficult than it at first appears. Because of the 
dynamic nature of the location of units, the road network, and the communications 
network, a real-time solution to this question is very important. A system that has real- 
time access to data about the roads and military units can provide the best possible 
answer to this question. 

In such an environment, with a dynamic road network and a dynamic 
communications network with distributed data and distributed computing power, the 
challenge is to develop a network and software architecture for models and algorithms to 
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operate in real-time and near real-time to help decision makers convert data into 
decisions. 

This thesis develops the requirements for this architecture in Chapter II. 
Chapter III describes some current technologies to be used in systems designed for this 
architecture. Chapter IV discusses in detail the design and development of a specific 
system to optimize the movement of people and equipment around a road network. 
Chapter V lists some other problems that could be solved using this architecture and 
Chapter VI provides conclusions for this thesis. 
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II. ARCHITECTURE 



The future battlespace will require many systems that will use the vast amount of 
available data to support decision making by a variety of users. Operations research 
models and algorithms can be used to convert raw data into information that can be used 
by these users. Even though these systems will differ in the data, models, and algorithms 
they use and in the users they serve, they can all be based on a single network and 
software architecture that is developed here. Developing a variety of systems based on a 
single architecture avoids the development of systems with different designs that are 
incompatible. 

The Architecture for Dynamic, Distributed Military Operations Research 
(ADDMOR) developed here is needed to help Army decision makers on the future 
battlefield. Systems based on ADDMOR synthesize the huge amounts of data that are 
collected by sensors on the network and refine it through the use of models and 
algorithms into a format that decision makers can use. A specific problem where a 
system based on ADDMOR can add great value is the efficient movement of men and 
equipment around the battlefield. This problem exists through the full spectrum of Army 
operations, from stability and support operations through major theater war. A system 
that can function at all of these levels can add great capabilities to decision makers and 
will have far reaching impact. 
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A. 



THE UNDERLYING COMMUNICATIONS NETWORK 



In the Army’s vision of the future, soldiers throughout the battlespace will operate 
digital computer devices connected to a communications network. These soldiers will 
perform many different functions and so will have many different hardware and software 
configurations on their local machines. These digital devices will communicate with 
each other on a network whose transfer medium may include High Frequency and FM 
radios, tactical satellite communications, and wire and fiber optic cable. They will all be 
able to communicate with each other because they will all use a low-level 
communications protocol such as Transport Control Protocol/Intemet Protocol (TCP/IP) 
used by the Internet. 

Figure 1 shows a diagram of a computer network. Connected computers will 
exchange information using the underlying communications network. This computer 
network will not require centralized control. It is not necessary that all communications 
be routed through a central computer that controls the network. The computer network 
does not need a homogeneous computing environment. Many different computational 
devices will be accessible on this computer network. They will range in power and size 
from personal digital assistants and cellular telephones through personal computers to 
large mainframes and super computers. These devices will have access to great amounts 
of data about the battlespace. These data could be distributed throughout the network, or 
they may be collected into a large data store that exists on one or more physical 
computers. 
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In order to solve the specific class of problems dealing with road movement, a 
system must have access to certain data about the physical environment and access to 
operations research algorithms to work on this data. In the future battlespace, data about 
the road network will be maintained in a data store that is connected to the computer 
network. These data will include road connectivity, road trafficability, travel times on the 
roads for wheeled and tracked vehicles, and capacity of roads in vehicles per hour. The 
collection and storage of the raw data will be done routinely. Access to this data is critical 
to using operations research to refine the raw data into decisions. Existing and future 
database technology is making great advancements in the areas of real-time data 
collection and access, and the military will benefit from much of this technology. 
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Data about military units will also be maintained in a data store. These data will 
include unit identification, unit location, unit size, and unit type. This data store may be 
physically located somewhere distinctly different from the data about the road network. 

It will also be accessible on the computer network. 

In addition to data, algorithms will be accessible on the computer network. In this 
class of movement problems, these algorithms can operate on graphs representing the 
roads and units in order to optimize movement on the road network. Examples of 
different graph algorithms that can help decision makers change data into decisions about 
road movement include shortest-path, maximum flow, minimum cost flow, and others. 

In the future environment, people connected to the computer network will need to 
solve problems and make decisions. These people will have varying levels of knowledge 
of operations research and its tools. Some users will be relatively naive, while others will 
be operations research analysts with a great knowledge of models and algorithms. The 
difference between the naive and expert user is their knowledge of operations research 
models and algorithms. For example, a naive user may be a medic in an ambulance who 
only needs to know the shortest path to a medical unit. The information he needs is a 
destination and how long it takes to get to that destination. An expert user may be an 
analyst at a Tactical Operations Center who is trying to plan the next position for a 
medical unit to move to. He may want to solve an algorithm to minimize the longest 
shortest path to any maneuver unit, and position his unit at that location. 

Different types of users is will use different computational devices to connect to 
the communications network. Current network devices include mainframe and personal 
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computers, hand-held digital devices and personal digital assistants, and even cellular 
telephones and pagers. ADDMOR systems should allow for a full range of 
computational devices, and be expandable to devices that are not yet even imagined. 
Future military operations will emphasize joint and coalition operations with forces that 
may have many different levels of organic technology, and many different hardware and 
software configurations. In this environment different users will have vastly different 
hardware running different systems software, and it will be unwise to mandate anything 
but the lowest level of software standards. Users should be able to operate in this 
environment as long as the user communicates on the network using an agreed upon 
standard low-level communications protocol. ADDMOR systems should allow any kind 
of hardware configuration and must operate on any and all conceivable platforms in order 
to be useful. These systems should also be able to scale up to larger networks, and they 
should be capable of evolving with technology as devices on the network move to 
different hardware and software configurations. 

Another challenge of working in the future battlespace will be the dynamic nature 
of the communications network. Computational devices will enter and leave the network 
frequently. Connections will change rapidly as units move within their zone of coverage. 
Message routes will change as units move physically and as different parts of the network 
become congested. All of these characteristics make robustness a design imperative. 

B. CLIENT-SERVER DESIGN 

Computer network architecture has moved through a few design paradigms in 
recent years that affect the operation of the network. Traditional mainframe computer 
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networks operated in a client/server mode with all of the computer processing taking 
place on the mainframe, and the client, (the user’s device), acting simply as a dumb 
terminal. This paradigm is not sufficient for work on a busy connected network, since 
the mainframe or server can be overwhelmed when executing simultaneous processes for 
multiple users. It also does not use the capabilities available with the more powerful 
client or user devices. With the growth of the Internet and the power of connected 
computing devices, systems have moved toward a thick client network architecture. In 
this case the network server acts as a file server, sending applications to the client 
computing devices where the programs are executed. In a thick client design most of the 
processing takes place on the client, and the server acts primarily as a file and data 
storage device. This network architecture places significant demands on data transfer, 
and suffers significant degradation when bandwidth between computers is limited and 
multiple users are trying to move large applications and data files to their own computers 
at the same time. [5] 
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Figure 2. Schematics of thick and thin client computer architectures. 
After Reference [5] 



The current trend is toward a thin client network architecture. This design 
framework is between the client/server architecture and the thick client architecture. In 
this case most but not all of the processing is done at the server; some processing is still 
executed at the client. One key advantage over the thick client architecture is that less 
data must be transferred across the network. This is an important benefit because current 
network limitations on bandwidth can slow the transfer of large applications across the 
network. Another advantage is that thin client design does not depend on powerful client 
side computers. This design places only minimal requirements on client side computing 
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power and memory. This thin client design should operate with many levels of future 
computing devices. 

In the future, connected environment units will sometimes operate autonomously, 
without the benefit of a network. For a system to be useful it should be able to operate in 
a stand-alone mode. In this mode, functions should appear to the user to operate the same 
as if the system were connected to a network. Some functionality may be limited due to 
lack of access to different algorithms and data, but the look and feel of the system should 
not change. The system should be able to optimize its operations to use different 
computational assets as these different assets are connected to the communications 
network. This could give the system different levels of functionality depending on what 
computer devices are cormected to the communications network. 

C. MODEL-VIEW-CONTROLLER 

An important design concept for systems is that the view of the world that the 
user gets is separated from the model used to represent the world in the computer. A 
controller between the model and the view of the user takes inputs from the user and 
forms them into a problem the model can solve. It then takes the solution from the model 
and converts it into a form the user can see and understand. The model does not need to 
know who the user is, his level of technical expertise, or the capabilities of his 
computational device. Similarly, the user does not need to know how the underlying 
model works. Whenever new algorithms are implemented, the controller can give those 
capabilities to the user without the user having to know how they are implemented. This 
separation of the user from the model makes it simple to change the model without 
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having to change the view of a user. It also makes it easier to customize a view for 
different user types without having to understand the underlying model. [6] Figure 3 
shows the how the model and view interact through a controller. 




Figure 3. Schematic of Model-View-Controller design 
With the separation of the model from the user it is very simple to update the 
algorithm without affecting the user. If a faster implementation of a specific algorithm is 
written, it can be plugged into the system without any change in how the system works 
for the user. The user does not need to know anything about the underlying system and 
how It works. Similarly, if a system designer thinks of a new user who only needs 
specific capabilities of the system, he can create a new view that interfaces with the 
controller. This view can be specific to this new user and may look totally different than 
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anything previously imagined. The underlying model will not change and the people 
creating the model need not have any knowledge of this new user and his new view. This 
capability to use the one model for many different user types each with a different view 
of the system is valuable. Separate models are not required for different types of users. 

D. MOBILE DATA AND ALGORITHMS 

One other challenge facing battlefield systems is the mobility of the road 
networks data, the units data, and the algorithms. These may either be stored on several 
different devices around the network, or in a centralized database. The user may know 
where this data is stored; in fact it may be on his machine. However, a system should not 
require the user to have any information about where this information resides on the 
computer network. A good design will allow for the data to be located in many places 
around the network. 

Computationally intensive models and algorithms should take advantage of the 
computational power in the computer network regardless of where it is located. A system 
should allow the hard work of actually solving the model to be moved to the most 
appropriate computational device available on the network. For more difficult, time 
consuming algorithms, the system could send the solution to a super-computer to be 
solved, while simple problems could be solved on less capable devices. This ability to 
use existing power in the system to solve problems enables the complexity of problems to 
increase as computational devices on the computer network become more powerful. The 
decision about which device to use to solve the problem might be invisible to the user. 

He does not necessarily need to know about the capabilities of the computer system, and 
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in many cases will not want to know. He just wants to know that at the instance he 
submits his problem, the system will marshal the best possible combination of data, 
algorithms, and computing devices to solve his problem. 

E. THE ADDMOR DESIGN 

As described above, the ADDMOR design consists of: 

1 . A communications network of heterogeneous devices based on a low level broadly 
supported protocol, 

2. A thin client network architecture with a model-view-controller design, and 

3. Data, models, and algorithms distributed over the communications network that 
can migrate over the network as it changes. 

In the last several years a number of hardware, network, and software 
technologies have emerged that allow systems based on ADDMOR to be developed. The 
next chapter describes these technologies and Chapter IV describes the Military Road 
Movement Optimizer, a decision support system for the movement of people and 
equipment around the battlefield that is based on the ADDMOR architecture. 



17 



THIS PAGE INTENTIONALLY LEFT BLANK 



18 



III. TECHNOLOGIES 



Design decisions must be made in order to build a specific system implementing 
the ADDMOR that meets all of the preceding requirements. 

A. TRANSPORT CONTROL PROTOCOL/INTERNET PROTOCOL 

In order to implement a useful, scalable and evolvable system that can help 
transform the large amounts of data on the network into decisions on the battlefield, users 
must be able to communicate with one another. The system requires a low level 
communications protocol, so that users can communicate with each other and with the 
data and algorithms on the network. Currently most digital networks use TCP/EP, a 
protocol developed to route messages effectively around the Internet and fully 
functioning on a wide variety of communications networks and computer devices. The 
military is developing a Tactical Internet that will also use TCP/IP to send information 
around the network [7, 8]. 

B. HYPERTEXT MARKUP LANGUAGE 

Given this communications protocol and a desire to have a thin-client 
architecture, systems need a common format for transmitting information back and forth 
between the user and the controller. This basic format should be the same for the entire 
range of users and applications. The well-known interface for users to interact with is the 
Internet is a web browser. A browser is capable of reading files in the Hypertext Markup 
Language (HTML) format. HTML is a language used to encode formatted text so it can 
be transferred over the Internet, and displayed on a variety of devices. It is a very low- 
level standard in use all over the Internet and the World Wide Web. Browsers are 
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available for most current devices including personal computers and personal digital 
assistants, and should be available for new devices in the future. By making the only 
requirement of a user that he have a web browser that can process an HTML message, 
ADDMOR systems allow for users without powerful machines. Users" devices do not 
need a lot of computing power to display solutions to problems. As network computing 
moves to smaller and smaller devices like cellular telephones and personal digital 
assistants, HTML browsers are some of the first applications developed for these devices. 
A system that takes advantage of this fact and interacts with users using HTML will be 
able to expand to these future devices with minimal effort. HTML allows for a truly thin- 
client architecture. 

Another advantage of HTML is the small size of files stored in this format. Since 
the data that does not include graphics is stored basically as text with a few formatting 
tags, it is not large in size. An HTML file consisting of 3 text characters is 212 bytes in 
length, while the same file saved in the Microsoft Word document format is 19,456 bytes 
in length. This is almost two orders of magnitude larger. The size of files is especially 
important when sending the information around a digital computer network. Smaller 
files can be sent more quickly and use less communications bandwidth. 

C. HTTP SERVER 

The thin client architecture using HTML requires that at least one device on the 
network is operating as a Hypertext Transfer Protocol (HTTP) server. These servers 
distribute web pages across a digital network. With the growth of the World Wide Web, 
many HTTP server implementations are widely available. Apache is a quite powerful 
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HTTP server that was developed and is maintained by the Apache Software Foundation. 
Apache is a robust commercial grade, open-source implementation of a server that is 
freely available for download on the Internet. It is also the HTTP Server in widest use 
today, being used by over 60% of all web servers [9]. The group that has developed 
Apache believe that a free implementation of an HTTP server is vital to the health and 
growth of the World Wide Web, so they have pledged to always distribute Apache free of 
charge. [10] 

D. JAVA 

The requirement that systems be able to operate on many different computer 
configurations led to the decision to implement them in Java. Java is a powerful platform 
independent computer language developed by Sun Microsystems. A program written and 
compiled in Java can be transported from one computer platform to a totally different 
computer platform without having to rewrite or recompile any of the underlying code. 

The only commonality between the two devices is that they both must have a Java Virtual 
Machine, a specific software implementation that translates Java byte code into machine 
instructions specific to that hardware device. Platform independence is an enabling 
property in an environment where the hardware components on the communications 
network are changing as quickly as the network itself The use of Java allows the 
system to be independent of the hardware configuration of the communications network; 
the program is inherently portable to other machines connected to the network. This is a 
very important idea, since the future operating environment will include other armed 
services in joint operations, other countries’ militaries in coalition operations, and other 
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governmental agencies and non-govemmentai organizations in stability and support 
operations. 

Another advantage of using Java is its capabilities to interface with databases. 

The JDBC Data Access(tm) API developed by Sun has many powerful tools for 
accessing, querying, and updating databases from other Java applications. This means 
that if the data about the roads and units is stored in databases, Java has built in tools to 
help access that data and use it in different models. Java’s JDBC capability allows 
programs to access data in virtually any existing or future database. It takes advantage of 
the low level Standard Query Language (SQL) that almost all current database 
technology implement to allow access to data in different databases. 

Java was originally developed as a computer language to harness the power of the 
Internet. Because of this it has many built in features that facilitate distributed computing 
operations. It has a very powerful and robust security model that can allow selective 
access to information and computer resources. Authentication and encryption are both 
implemented in Java. These tools are especially important in a military environment 
where access to information must be controlled. 

Java also has the ability to dynamically load programs from across a 
communications network. An executing Java class or program can query another 
computer on the network to find out what compiled programs it has available. The 
executing program can then download and execute one of those programs, without 
stopping the current execution. This is a very powerful idea that greatly extends the 
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functionality. The first program does not need to know which programs are available 
ahead of time; it can choose from the list of currently available programs. [11] 

E. SERVLETS 

Servlets are a tool developed using Java that allows users on a client machine to 
run applications on the server. A servlet runs completely on the server side of the network 
rather than on the client computer. A servlet generates HTML for the client, usually a 
web browser. The user or client does not need to have a Java Virtual Machine on his 
device, and in fact needs to have no knowledge of the existence of Java on the server. 

The Java servlet API provides powerful tools for programs so that they can operate on the 
server and can serve HTML back to the user. The servlet is a fully functioning Java 
program located on a server that runs when a user points his browser to the web address 
of the servlet. The servlet has all of the previously mentioned powerful capabilities of 
Java including platform independence, database connectivity, distributed computing, 
security, and dynamic loading. Because it is implemented in Java using the servlet API, 
it does not suffer from many of the shortcomings of other server side applications that use 
the Common Gateway Interface (CGI) implementations. Also servlets tend to be more 
efficient than CGI scripts. [5] 

In order for a servlet to work, the machine it is operating on must have a web 
server, such as the HTTP server developed by Apache, and a servlet engine. A popular 
servlet engine that has been specifically designed to operate with the Apache server is 
Apache JServ, developed by the Java Apache Project.[12] JServ allows servlets written 
in Java to operate on the network and to serve web pages to users on the network. It is a 



23 



powerful, award-winning software implementation that is widely available on the Internet 
at no cost. 

The HTTP server allows users to connect to the system with a HTML browser, 
and the servlet engine allows servlets to execute, giving all of the capabilities of Java. In 
this design, user devices must only be able to process HTML encoded text. Their view of 
the system is just the HTML page they are presented with. A servlet acts as the controller 
between the user’s view and the operations research models. A user enters information 
into an HTML form. This information can either be entered by the user, or can be built in 
and even hidden in the form. The servlet parses this form after it is submitted, and sends 
the input parameters to a model interface that determines which model to use, and how it 
should operate. The model executes, and sends results to the model interface that sends 
the solution to the servlet based on the input parameters. The servlet then send this 
solution back to the user as a HTML encoded text. 

If a user wants to operate autonomously as a stand-alone system not connected to 
the computer network, he can still use the servlet. He must have an HTTP server, a 
servlet engine, the specific servlet he wants to use, and a web browser on his machine. 

The user’s view of the servlet is the same as if he were accessing it remotely. 

F. KONIG 

One existing software tool in Java that the proposed system uses to solve network 
algorithms is Konig. [13] Konig represents graphs as Java objects and can solve many 
different graph algorithms on these graphs. It has the ability to store various properties of 
the nodes and the arcs that make up the network. Because it is implemented in Java, 
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these properties can be information that is stored and accessed from existing databases. 
A graph can be created from information that is stored in different data formats on 
different computers. Konig can then dynamically load algorithms, if necessary from 
different computers, and execute these algorithms on that graph in order to get solutions 
that can assist decision makers. From an operations research standpoint, Konig provides 
the power to model networks and to analyze the raw data about the network using 
existing algorithms. A Konig graph is the specific network model that is used in this 
implementation, but others could be used in other implementations. 
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IV. MILITARY ROAD MOVEMENT OPTIMIZER 



A specific system based on ADDMOR was implemented to support decision 
making about the movement of military equipment and personnel across a road network. 
The Military Road Movement Optimizer (MRMO) uses the ADDMOR architecture 
described in Chapter II and the current technologies described in Chapter III to provide 
users with a system that helps them make road movement decisions. 

A. DISTRIBUTED DESIGN 

The power of the MRMO is that it is designed for a distributed network. Figure 4 
shows how different parts of the system can exist on distinct hardware devices connected 
by a digital network. Each distinct box in the figure represents functions that can be on 
separate computers connected to the network. The user’s digital device is running a web 
browser. His view of the system is provided to him via HTML pages. He accesses a 
servlet by connecting to a computer acting as a server by pointing his web browser to the 
address of the servlet. This server is running an HTTP server and a servlet engine. The 
server passes the user’s request to the servlet running on the same machine. The job of 
the servlet is to interface with the operations research model of the road network and to 
control the view the user has of this model. Each servlet creates HTML pages specific to 
the type of user and his requirements. All of the MRMO servlets take information input 
by the user and send it to a single application that is the model interface. The model 
interface retrieves data about the road network and creates a Konig graph from that data. 
Road network data can exist on any computer connected to the network. It can be stored 
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in a flat data file or in a database. The servlet retrieves data about units in the battlespace 
and adds that data to the Kdnig graph model of the road network. Again, unit data can 
exist anywhere on the computer network. The model interface then finds the appropriate 
algorithm to execute on this graph. Algorithms can also be distributed throughout the 
network. The result of executing the algorithm is returned to the servlet, which formats 
this result in a format appropriate for the specific user and returns them to the user as an 
HTML page. 



USER 

(WEB BROWSER) 




Figure 4. A distributed computing MRMO implementation 
The MRMO system consists of several servlets that allow different types of users 



to interact with this model in order to help them make decisions. Each of these servlets 
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uses the same model interface to interface with the model. Each servlet formats the 
model’s output into HTML pages tailored for the specific user that servlet is designed for. 

B. THE MEDIC 

One servlet interacts with a company medic on the battlefield. This medic is 
moving around the battlefield with a specific unit. When that unit takes casualties the 
medic needs to know the location of the nearest aid station so that he can evacuate those 
casualties to the next level of medical care. Currently the company gets information 
about the status of road networks and medical unit locations from voice radio 
transmissions and stores that information on a map. If in the heat of battle an updated 
unit location is not heard or if the map is updated incorrectly, these data will be wrong. 
The procedure to find the nearest aid station is to look at the map and then estimate the 
distance to the aid station. This system is fraught with error and can benefit greatly from 
a system designed to harness the power of the ADDMOR. 

Figure 5 contains a view of the introductory HTML page that the servlet 
constructs for a medic in Microsoft’s Internet Explorer web browser. The medic enters 
the name of the unit he is located with and hits the ‘SUBMIT’ button. This HTML page 
contains other inputs for the model as hidden text that the user cannot see. This hidden 
text includes the name of the algorithm and the values of the parameters for that 
algorithm. By including this information as hidden text, the user does not need to know 
anything about the algorithm. 
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Figure 5. The medic’s introductory screen 
Figure 6 shows how the HTML page looks when viewed on a small personal 
digital assistant. The Palm Pilot is 4.7 inches tall by 3.2 inches wide. It weighs only 6 
ounces; it is very portable and is an example of the types of small digital devices on the 
connected battlefield. Because this servlet is designed to return simple text files without 
pictures or huge displays, it is able to work well within the limitations of the personal 
digital assistant’s small size and display. 
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Figure 6. The introductory screen viewed on a Palm Pilot. 

Figure 7 shows the solution page returned to the medic by the servlet listing the 
name, location, and distance to the nearest aid station. The time that the data was sent to 
the model is also returned to the user. In order to update this result the medic clicks the 
‘BACK' button on his HTML browser and then can resubmit the input data to solve the 
algorithm again. Each time the medic clicks ‘SUBMIT’, the controller creates a current 
graph of the road network and units by reading from a data store (in the current 
implementation, two flat text files). The model invokes an algortihm to compute the 



31 




shortest path from the entered source node to all other nodes in that graph. This 
intermediate solution is then searched for all units that have a unit type equal to 
“medical”, and the medical unit with the lowest valued shortest path distance is selected. 
All properties of that unit are returned to the servlet by the model. The servlet for the 
medic is designed to display the name, location, and shortest path distance to the nearest 
medical unit. 




Figure 7. The medic's solution screen 

Figure 8 shows the same solution viewed on a Palm Pilot. Since the servlet was 
designed to return a very simple web page using plain HTML, it is easily viewed with a 
very simple device with a small display. This is perfect for users who cannot afford to 
carry large display devices with them due to weight and size constraints. 
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Figure 8. Solution screen viewed on a Palm Pilot 



C. THE EXPERT USER 

Another MRMO servlet is tailored for an expert user. An expert user has a better 
knowledge of operations research models and graph algorithms. He is located at a 
command post and has access to a more powerful computational device. 
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Figure 9 shows the view that an expert user of MRMO sees. This HTML form 
allows him to select the type of device he is operating on and the algorithm he wants to 



solve from pull-down menus. When he clicks ‘SUBMIT’, a new HTML page is 
dynamically created based on the algorithm he selected. It will have entry fields for 
parameters specific to the algorithm he selected. Note that the display in this figure is 
viewed using a Netscape Navigator browser window, as opposed to the Microsoft 
Internet Explorer browser used by the medic. As mentioned in Chapter III, these servlets 



can be accessed from any web browser, and are not tied to a specific software vendor. 
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Figure 9. Expert user introduction page 
Figure 10 is the page displayed when the expert user selects a shortest path 
algorithm. At the top of the page is the name of the algorithm that the servlet will call in 
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the model. On the left are names of the parameters that must be input to the model. In 
the center are text boxes where the user can enter values for these parameters. In this 
case the user has typed specific entries into the text fields. After each text field is a list of 
possible entries for that field, or a prompt for a specific entry. As mentioned earlier, this 
page is created dynamically based on the user’s entries in the previous page. The 
parameter names and prompts are read from a file at the time the page is created. When 
new algorithms are added to the model, the model developer must simply modify this one 
file and the view will be updated. 
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The expert user clicks ‘SUBMIT’ and the servlet puts his entries into the proper 
format for the model. The model runs and returns a solution to the servlet. The servlet 
converts that generic solution into the specific solution type the user requested and in a 
format appropriate for the user’s computational device. 

Figure 1 1 shows the expert user’s solution page. This solution shows the user the 
parameters he entered for the problem and the solution to his request. In this case the 
user asked for a path from his location to the nearest medical unit. It is displayed as a 
sequential list from his location through a series of road intersection checkpoints, to the 
final unit. 
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As in the medic’s solution, the solution is identified by the time that the data was drawn 
from the data store. The user knows that if changes to the road network or unit locations 
occur, he must resolve the algorithm. Resolving the algorithm is a simple matter of using 
the ‘BACK’ button in his web browser, and clicking the ‘SUBMIT’ button again. If he 
wants to change the algorithm, he must simply return to the introductory servlet page. 

If the expert user’s device is able to display maps and geographically referenced 
data, the servlet can return an overlay that shows the route from the user to the nearest aid 
station. In Figure 12, the route from the artillery unit at the top right of the map to the 
medical unit in the lower left is displayed on the map in red. 
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Each of these interfaces, or views, that the user gets of the system use the same 
model and the same controller. The entries and hidden text from the HTML form are put 
into an HTTP request by the servlet. When the user clicks ‘SUBMIT’, the controller 
creates a hashtable from his entries on the form. (A hashtable is a data structure that 
maps keys to values with keys being are strings listing the parameter names, and values 
being strings identifying the parameter values.) A user can access any parameter value if 
he knows the parameter name. 

The controller then instantiates a model interface with the hashtable of 
parameters. The model interface connects to the current information about the roads and 
units and builds a graph based on this information. The time the data was accessed is put 
into a hashtable that will be returned to the controller. A specific algorithm is executed 
on this graph based on the value of the algorithm parameter that the user entered. Based 
on the solution type parameter, the model interface formats the solution in the form that 
the user asked for. The model interface then puts the solution into the hashtable, and 
returns this hashtable to the controller servlet. 

The servlet takes the hashtable containing the solution, and builds an HTML page 
for the user that is in a format appropriate for the user’s computational device. The 
format of this page depends on the type of display the user’s device has. 
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V. OTHER PROBLEMS 



Systems based on an ADDMOR design can help decision makers in many 
military environments. Following are some specific military problems, and how these 
tools can help solve them. 

An artillery battery supporting a Brigade attack occupies a new position and fires 
a mission. They immediately are attacked by enemy counter-battery artillery fire and 
begin to take casualties. They must evacuate these casualties as quickly as possible to a 
medical aid station or soldiers will die. The decision the battery first sergeant must make 
is where to move the casualties. Medical service in the army is an area support function. 
The first sergeant should obviously take the soldiers to the aid station that is closest. 
Since the battle is dynamic, the aid stations are moving to support the brigade. The 
battery first sergeant is not always monitoring the correct radio frequency to hear the 
current aid station locations. A system such as MRMO can quickly solve his problem of 
finding the nearest aid station. It also avoids the problem of operating from old or 
incorrect data. By operating from a centralized database, the first sergeant’s decision can 
be optimized using the most current data. 

A division arriving into theater must move over an existing road network to the 
forw'ard battle area. The decision for the division’s plans section is how to optimize this 
movement in order to minimize the time required to move the division to the forward 
area. An ADDMOR system can help the plans section optimize this movement. A 
system that implements a minimum cost flow algorithm on the road network could 
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optimize the movement. The movement can be planned before the division arrives in 
theater. As conditions on the ground change, the planners can resolve the problem, and 
issue fragmentary orders to the units to keep the movement optimized. 

The Corps Support Command needs to send an ammunition convoy forward to 
drop ammunition at four different Ammunition Transfer Points (ATPs) in the Division 
Rear Area. The Corps logisticians must make two decisions. First, where should the 
ATPs be located, and second, what route should the convoy take to see deliver to all four. 
The first of these problems may require minimizing the longest route a customer of that 
ATP must travel to receive ammunition. Or it may require minimizing the average route, 
or minimizing the route of a specific customer unit. An ADDMOR system that is set up 
to solve this longest shortest path algorithm recursively will greatly help the planners 
locate their ATPs. The second problem, what route to take, stands out to an operations 
research analyst as a classic traveling salesman problem. What is the best route to take to 
go to all of these points and return to the Corps rear area? A system that implements a 
traveling salesman algorithm can help the logisticians plan the best route for the trucks to 
take. As the battle progresses, road conditions change, and units move; the problem can 
be solved again. The system could be customized to solve these two problems 
sequentially, so that it returns the ATP locations and the route to them. It could also 
allow a planner to set some or all of the ATP locations as input to the algorithm. 

A Joint Targeting Team is planning to interdict an enemy road network. This flow 
interdiction problem may have the objective of minimizing residual movement along the 
road network between some specific points, or it may be trying to maximize the time to 
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travel between two points in the road network. The planners must decide where they 
should attack the road network to maximize damage to the enemy. An ADDMOR 
system designed to solve this interdiction problem could be of great value to the targeting 
cell. As attacks occur, and repairs are made to the road network, the problem could be 
solved again to plan further attacks. 

The architecture of an ADDMOR system is extremely relevant with today’s 
military emphasis on joint, coalition, and interagency operations. It can add benefits over 
the full spectrum of combat. In humanitarian assistance scenarios, operating with other 
government agencies, foreign governments, and international relief agencies, this 
architecture allows for all people working on the project to come with their own 
computer systems and devices. If they can share access to their computer networks, they 
can all have access to the same powerful operations research tools to help them make 
decisions. 

Systems based on the ADDMOR design can use models other than network 
optimization. They could also be used to run a discrete-event simulation to help a 
decision maker make a decision. An example of an operations research model that could 
be accessed using this architecture is the convoy simulation developed at the Naval 
Postgraduate School by Norbert Schrepf [15]. This is a stochastic discrete event 
simulation that models the movement of convoys over fixed road networks. Another 
model that could benefit from this architecture is the model for coordinating inland area 
search and rescue developed by Timothy Castle [16]. This model creates a probability 
map for the likelihood of finding the target. The probability map is updated as negative 
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search results are obtained using Bayes Theorem. As data about the search changes, the 
solution can be updated and a new optimal distribution of search assets returned to the 
user. 
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VI. CONCLUSIONS 



Future military visions are based on using the digital battlespace to obtain 
information superiority and dominant battlespace awareness. One important aspect is 
converting data into information that is valuable for decision makers. Operations 
research provides many tools to help distill raw data into information that helps people 
make decisions. A challenge for the future environment will be to design systems that 
combine the large amounts of data collected about the battlefield with powerful 
operations research models in real-time and near real-time to provide useful information 
for decision makers. 

The road movement system developed here takes a dynamic road network and a 
d)mamic communications network with distributed data and distributed computing power 
and combines them with an operations research model to solve road movement problems. 
The system harnesses the power of currently available, free technologies to convert real- 
time data into decisions. Because it was designed using low-level communications 
protocols, the system is accessible from different hardware platforms. This capability of 
the road movement system was shown by accessing it from a personal computer and a 
Palm Pilot personal digital assistant. The proven ability to access data on the network 
and to execute an operations research algorithm on that data, all from small digital 
devices in real-time and near real-time, demonstrates the potential operations research has 
to offer decision makers on the future battlefield. 
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